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.SYSTEM AND METHOD FOR ELECTRONIC TRANSMISSION, 

^STORAGE AND RETRIEVAL OF AUTHENTICATED DOCUMENTS 

This application is a continuation-in-part of U.S. Patent Application No. 09/737,325 filed 
5 on December 14, 2000, which is a continuation of International Application No. 

PCT/US00/32746, filed on December 1. 2000, that designates the United States, and a 
continuation-in-part of U.S. Patent Application No. 09/452,928, filed on December 2, 
1999, now U.S. Patent No. 6,367,013. which is a continuation-in-part of U.S. Patent 
Application No. 09/072,079 filed on May 4, 1998, now U.S. Patent No. 6,237,096, which 
10 is a continuation-in-part of U.S. Patent Application No. 08/528,841 filed September 15, 
1995, now U.S. Patent No. 5,748,738, which is a continuation-in-part of U.S. Patent 
Application No. 08/373,944 filed January 17, 1995, now U.S. Patent No. 5,615,268. all 
by Bisbee et al. This application claims priority to the filing date of U.S. Provisional 
Patent Application No. 60/397.178 that was filed on July 18, 2002. These patents and 
applications are incorporated in this application by reference. 



BACKGROUND 

Applicants 1 invention relates to systems and methods for providing a verifiable 
chain of evidence and security for the creation, execution, maintenance, transfer, 
retrieval and destruction of electronic original information obiectS r. such as Electronic 
Original™ documents. 

This invention e xpands on advantageously uses A pplicants' Trusted Custodial 
Utility that holds electronic original records and comparable system roles as a virtual 
electronic vault in validating the right of an individual to perform a requisite action, the 
authenticity of submitted electronic information objects, and the status of the 
authentication certificates used in the digital signature verification and user 
authentication processes. Such TCUs and operations are described in U.S. Pa tents No. 
5.615.268: No. 5.748.738: No. 6.237.096: and No. 6.367.013. " 

The following list of acronyms abbreviations is used in this description: 
Acronyms 

B2B Busin e ss - to - Busin e ss 

B2Q Busine ss - to- Co ns u m e r 

Abbreviations 

CA Certification Authority 

GAP Cont i nuat i on in part 

GP C e rtificat e Pol i cy 

CRL ^Certificate Revocation List 

CSS ^Certificate Status Service 

HTML hypertext Markup Language 

ID Identification 

IETF internet Engineering Task Force 



-2- 



1 



Patent Application Ser. No. 10/620,817 
Mark-Up of Specification in Accordance with MPEP 704.1 1(a) 



ITU international Telecommunications Union 

LDAP lightweight Directory Access Protocol 

OCSP = Online Certificate Status Protocol, IETF-RFC 2560 X.509 Internet 



PIN — 
PKCS- 
PKI — 
PKIX- 
RA 



SSL- 



Public Key Infrastructure Online Certificate Status Protocol - OCSP, June 
1999. 

- = Personal Identification Number 
- = Public-Key Cryptographic Standards 
- = Public Key Infrastructure 
- = Public Key Infrastructure (X.509) 
R e gistrat i on Author i ty 



RSA R i v e st Sham i r Adl e man (pub l ic k e y algor i thm & company) 

S/MIME JBecure Multi-Purpose Internet Mail Extensions 

SCVP pimple Certificate Validation Protocol, Draft-IETF-PKIX-SCVP-06, 



July 2000 

SHA - 1 S e cur e Hash A l gor i thm R e vis i on 1 



- = Secure Socket Layer 



TCU Truste d Custodial Utility 

UETA ^Uniform Electronic Transactions Act 

URI Un i form R e sourc e Id e nt i fi e r 



URL- 



Uniform R e sourc e Locator 



XML- 



- = Extensible Markup Language 



The U.S. Electronic Signatures in Global and National Commerce Act (-ESIGN-) 
legislation and U.S. state laws modeled after the Un i form El e ctron i c Transactions Act 
fMJETA^) drafted by the National Conference of Commissioners on Uniform State Laws 
and approved and recommended for enactment in 1999 provide c e rta i n assurances of 
legal standing for electronically signed information objects (electronic documents) which 
has generated government, banking and electronic commerce activity aimed at realizing 
the efficiency and economies of these potentially wholly electronic transactions. 
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Publ i c K o y I nfrastructur e ( PKI) and the Certification Authority ( CA) are the 
b e drock base elements of digital signature technology used in creating electronic source 
records. A PKI is a collection of CAs where trust is established between users and user 
organizations by creating either a hierarchical relationship between CAs or through 
cross-certification amongst cooperating CAs. A CA is empowered to issue 
authentication certificates that bind an individual's or entity's identity to his or its public 
key (verifying), where only the individual is given access to the matching private key 
(signing). At the time of this application, certificates normally conform to the 
I nt e rnat i onal T ele commun i cations Union ( ITU) X.509 certificate standard and are 
10 themselves digitally signed by the issuing CA. Such certificates are depicted in FIG. 10 
of U.S. Patent No. 6.237.096. for example, that is cited and incorpora ted above. These 
authentication certificates contain a serial number, identifying information of the subject 
(user) and issuer (CA), the certificate's validity period (date and time before and after 
which it may not be used), the subjects subiect's public key, and cryptographic algorithm 
15 information needed to create and verify digital signatures. 

To create a digital signature ± an information object is hashed (processed using a 
one-way cryptographic function that can detect as little as a one bit alteration in the 
object) and the hash is then encrypted using the individual's private (secret) key. Digital 
signature verification is achieved by reversing this process. The digital signature is 
20 decrypted using the individual's public key retrieved from their authentication certificate 
and the result is compared to a re-hash of the original information object. These 
processes may vary when using different digital signature algorithms. Digital signatures 
are only as reliable as the trust that exists between the relying parties and the issuing 
CAs; and the level of assurance achieved by the physical controls, practices and 
25 procedures implemented by the CAs. 

The purpose of PKI technology is to create and maintain both a secure and 
trusted environment for communicating parties. Such parties rely on the PKI to 
establish the identity of users and to notify them when a user's certificate is no longer 
viable. Certificates are revoked when an individual leaves an organization, when a 
30 replacement certificate is issued, or when a signing key is lost, stolen or compromised. 
Vendors report certificate status using a wide variety of methods. These diverse 
methods make it more difficult for users to obtain certificate status for other users. 

The formation of a trust relationship and interoperability is dictated by PKI 
certificate and security policies and their enforcement. The certificate policy determines 
35 the level of personal vetting (i.e., the process for validating appropriateness of certificate 
request information and the identity of the intended certificate recipient) required (e.g., 
two forms of picture ID, credit check) to gain approval for issuance of a certificate. The 
security policy dictates the physical, procedural and process controls needed to support 
| the application environment. 
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| There are two prevalent models for creating and organizing CAs. The first is a 

hierarchical CA model that resembles an inverted tree whose top is the root CA. The 
root CA signs its immediate subordinate CAs' certificates. These CAs then sign their 
subordinate CAs 1 certificates, and so on. These relationships create certificate chains 
that form oach branch branches of the tree. Two CAs prove that a trust relationship 
exists between them by "walking!! their respective certificate chains until a common node 
is reached. CAs may be grouped and associated with one or more service delivery 
channels, industry verticals, organizations or enterprises. 

In the second model, a CA is created for a single enterprise and provides CA 
10 services to one or more entities within that enterprise. An enterprise CA does not 

normally have any pre-established trust relationships with any CA of another enterprise. 
Explicit action must be taken to allow interoperability in the form of CA cross- 
certification, whereby two or more CAs that agree to trust one another sign each other's 
certificate and use these cross-certified certificates during digital signature verification. 
15 Certificates issued by one CA can then be validated by the other cross-certified CA and 
its users. 

CAs revoke certificates when , among other r easons, the information contained 
therein becomes invalid, when the user's private key becomes compromised, or when it 
j is necessary to terminate a user's certificate-based application privileges. CAs cannot 
20 simply delete or retrieve a certificate from its owner if it is already in the owner's 

possession. Instead^ the certificate is marked as "revoked" in the CA ? s database and 
th^certificate status ^published. Users of the PKI can then learn of a certificate's 
validity by requesting certificate status from the issuing CA or identified status repository 
(directory). 

25 An early method used to report certificate status was by way of publication of a 

list of a CA's revoked certificates, known as a C e rt i ficat e R e vocat i on L i st ( CRL). CRLs 
are downloaded by applications and relying parties to determine whether a particular 
user's certificate has been revoked and by extension whether that user's digital 
| signature is still valid or not. With time i CRLs get longer, incurring both communication 
30 and data processing overhead. An additional shortcoming of this approach is that CRLs 
| are often published at infrequent intervals (e.g., once or twice a day). For this reason, 

CRLs are often immediately out-of-date after publication. Revoked certificates are only 
| removed from CRLs after certificate expiration. 

A PKI bridge is a method of providing interoperability between CAs by 
35 coordinating distribution of CRLs. Such a bridge is a central CRL repository that in 
effect joins a set of CAs that agree to accept each other's certificates and security 
policies. All CAs post their CRLs to the bridge. This allows for centralized validation of 
any i ndividuals ' individual's or e ntiti e s' g Dlit^certificate. If the certificate has not been 
previously revoked, than then it is still considered valid. The biggest disadvantage to 
40 ( PKI bridges is that they must be reachable by any CA or user relying on the bridge for 
certificate status. The bandwidth, computation and storage requirements may be 
costly. 

A more recent method for obtaining certificate status is the I nt e rn e t Engin ee r i ng 
Task Forc o ( IETF ) On li ne Cortificato Status Protocol ( OCSP ). OCSP . which makes a 
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direct database query that can provide real-time certificate status. However, some 
vendors have implemented OCSP responders that are based on CRLs. Certificate 
status reported by this type of responder is only as timely as the CRLs on which they 
are based. Attempts to achieve real-time certificate status, such as the IETF Simpl e 
C e rt i ficat e Va li dat i on Protocol SCVP continue to be developed. At the time of this 
invention, mixing and matching of status checking methods has not been practical in an 
open PKI environment. 

Any approach to certificate validation is an all-or-nothing decision for the CA that 
issued the certificates. All users who are issued certificates by one of the member CAs 
[ are valid/enabled unless their certificate has been suspended-jojirevoked or has 
expired. The common theme for controlling participation is whether a certificate gets 
issued. Issuance is governed by certificate and security policies and business rules. 

The trust environment can be -ranqe from fully open ± where anyone able to pay 
the price of admission is issued a certificate, to b e ing closed or bounded ± by requiring 
membership in an enterprise or community of interest. In either case ± CA certificate 
and/or security policies govern whether interoperability is allowed. 
SUMMARY 
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Applicants' invention approaches the PKI and CA interoperability problem from a 
totally different point of view than tha t from those described i n th e background section. 
As i n above. Applicants' e arli e r inv e ntions, th e focus is on establishing a trust 
environment suitable for the creation, execution, maintenance, transfer, retrieval and 
5 destruction of electronic original information objects that may also be transferable 
records (ownership may change hands). To realize these objectives, the system 
controlling an electronic original or authoritative copy must make it possible to identify 
| the original from any copy thereof. As with paper orig i na l oriqinals. there can only be 
one original. Examples of transferable records are electronic negotiable instruments 
10 and securities. An electronic original record may be any source record, whether it 

| qualifies as a transferable record or not. Transfer of electronic or i gina l s original records 
between systems must take place using methods that guarantee that only one original 
exists. 

This invention creates an electronic original record by placing custody of that 
15 record in the hands of a trusted independent party, functionary or Trust e d Custod i a l 

Utility ( TCU) operated for the benefit of the record's owner. Creating a trust environment 
is a-necessary, but is not sufficient for maintaining electronic source records. For the 
purpo s e purposes of this invention, a trust environment is created by formation of a 
community of interest that has a closed or bounded membership and where the identity 
20 | of prospective members, organizations and their users T is assured by using appropriate 
vetting procedures that govern the granting of admission to the community. Further, an 
| individual's organization, participation, role ± and attributes are defined at the time of 
enrollment with the TCU. Individuals must be uniquely identified to the system and in 
their authentication certificate. In addition, it must be possible to remove individuals and 
25 organizations from the community and to make this action known to other members of 
the community. Traditional approaches to CA interoperability do not adequately achieve 
these objectives. 

Vetting T at a minimum requires that an organization and/or individual be 
sponsored by a known member of the community. In addition, a Dun and Bradstreet-Pk 
30 nkg rating for organizations or an Eau*fax-f?i -like credit check for individuals, or an 
equivalent credit and payment history ± may be utilized to evaluate acceptability of 
potential business partners, clients and customers. Both the vetting organization 
and its sponsored users must be deemed trustworthy before TCU enrollment is 
permitted. After an organization agrees to the contractual terms defining 
35 membership, its sponsored individuals will each be given a unique identifier and 
password that will enable them to access the TCU. 
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Once an individual is enrolled with one or more TCUs ± they can be named 
as a participant to a transaction by the owner of that transaction and given 
specific access to all or an identified subset of source records based on their 
identity, role ± and/or responsibility. To facilitate identification and authentication 
and to enable the transactions to take place in a totally electronic form, a selected 
subset of this identifying information is included in the participant's 
authentication certificate. The authentication certificate binds the user's identity 
with their public-key used to validate digital signatures generated using their 
matching signing private-key. 

A certificate or security policy addresses the proof-of«identity requirements 
(e.g., two forms of picture ID, credit check, personal introduction) needed before 
issuing a certificate. This certificate will be bound to the user's TCU account if 
required for digital signing authority. The linkage shall include a subset of 
certificate data elements that uniquely identify the user (e.g., certificate ID, issuing 
CA name, user common name). Once associated with a user's account, the 
certificate can be used in conjunction with his or its digital signature to afford the 
proof-of-identity needed to enable a predetermined set of authorized actions and 
to verify the user's digital signature on submitted information objects. This is 
especially true when the owner or owner's agent controlling a set of electronic 
records T instructs the TCU to transfer ownership (i.e., an internal transaction) 
and/or to transfer custody (i.e., an external transaction) of the electronic records 
to another TCU. 

As described earlier, authentication certificates and public-key 
cryptography are used to support both user authentication and digital signature 
verification. The certificate is digitally signed by the issuing CA, a process by 
which the identity of the recipient is sealed with their public key. The CA asserts, 
in issuing a certificate, that the individual identified in the certificate is the holder 
of the matching private key used to digitally sign information objects or fragments 
thereof. 

This invention differs from other PKI-based e-commerce solutions since 
the PKI is only viewed as enabling and is not the sole basis of the trust 
environment. Sponsorship, contracting for membership, and enrollment are the 
principal factors. Although the certificate and use of public-key cryptography are 
viewed as enabling technology, certificates must uniquely identify and be tied to 
the specific users before they can be bound to that user's TCU account. 
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Where certificates are employed, the account may only be activated once 
this binding between certificate and user account is completed. This binding may 
be as simple as adding the Certificate ID and Issuing CA to the user's account 
information or may use other information conveyed by the certificate such as 
components of the user's distinguished name (see ITU X.509 standard). The 
binding information may be conveyed in an enrollment form or extracted directly 
from the certificate as per TCU system security policy. A correspondence check 
may be used to ensure that the user description in the certificate matches that in 
the enrollment data whenever the certificate is used. The user's certificate is 
signed by the issuing CA and its integrity and authenticity are validated using the 
issuing CA's certificate and public key. The collective set of components used for 
identification must be provably unique. Once this TCU account and user 
certificate binding is accomplished, the TCU need only know where to go to check 
certificate status. 

In CA centric environments, a single PKI, cross-certification, or creation of 
PKI bridges (a complex system that performs certificate status checking where 
multiple vendor products are used by numerous CAs) is required for 
interoperability. The common element is that ail certificates are of equal value. 
Certificates may convey different trust levels and applications in an open 
environment must have the ability to interpret and use these trust levels 
differently. This philosophy can be characterized as "we will build roads that will 
take you anywhere you want to go". Users are vetted upon CA enrollment using a 
variety of criteria (e.g., a credit check, means of payment, cost of the certificate). 

A TCU, conversely, is only concerned with a known set of "approved CAs" 
and within that set only those certificates that are associated with its user 
accounts. Any other certificate will be ignored. This philosophy can be 
characterized as "the only roads that will be open to you will be those needed to 
conduct your business". Users are vetted twice, once to satisfy the CA certificate 
policy and a second time to prove that there is a business need for them to be 
enrolled with a TCU. Business rules enforced by the TCU can accommodate 
certificates that are issued at different trust levels. 

SUMMARY 

To date, all certificate status reporting services use a single means of 
reporting certificate status, be it CRLs, OCSP, LDAP, etc. This invention differs in 
that it enables interoperability with any CA or PKI for the purpose of retrieving 
and reporting certificate status. For the most part it also reduces reliance on 
real-time continuous connectivity between the systems or TCUs and the CA 
certificate status reporting elements, by caching certificate status. 

In one aspect of Applicants' invention, a method of providing a CSS for checking 
validities of authentication certifica tes issued bv respective CAs includes the steps of 
identifying information needed for retrieving a status of an authentication certificate from 
an issuin g CA th at issued the authentication certificate: configuring a connector based 
on the identified information for communicating with the issuing CA; communicating with 
the issuing CA according to the configured connector: and retrieving the status of the 
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authentication certificate. The issui ng CA a nd the connector are designated on a list of 
approved CAs in a configuration store. 

A local date and time may b e checked for whether they fall within a validit y period 
indicated in the authentication certificate validity period. The issuing CA may be 
included in the list of approved CAs by vettin g and ap proving the issuing CA according 
to predetermined business rules, and if the issuing CA is vetted and not approved, the 
issuing CA may be designated on a list of not-approved CAs in the config uration store- 
Vetting and approving the issuing CA may include reg istering a representation of a 
trusted authentication certificate with the CSS and adding at least the representation, 
status and a time-to-live data element to a local cache memory. A connector is then 
configured for retrieving the added status when the status of the t rusted a uthentication 
certificate is Queried. Communicating with issuing CAs may also be done according to a 
seguence of connectors. 

The method may fu rther include checkin g a local cache memory for the status, 
and if the status is found in the local cache memory and the local date and time are 
within the validity period, retrieving the status from the local ca che mem ory. If the status 
is not found in the local cache memory or if the local date and time are not within the 
validity period, the CSS establishes a communication session with a certificate status 
reporting component of the issuing CA. composes a certificate status reouest according 
to the configured connector, retrieves the status from the certificate status reporting 
component, closes the communication session with certificate status reporting 
component, and adds at least the authentication certificate's identification . status r and 
time-to-live to the local cache memory. 

Certificate status mav be indicated bv a CRL. and according to a publication 
schedule of the issuing CA. the CSS retrieves the CRL from a certificate status reporting 
component listed in the configuration store, the CSS clears a cache memory associated 
with the issuing CA T and the CSS determines the status of the authentication certificate 
from the CRL and stores the status in the cache memory associated with the issuing 
CA. 

Certificate status mav also be indicated by a Delta Certificate Revocation List 
r'ACRL"). and upon notification bv the issuing CA that a ACRL is available, the CSS 
retrieves the ACRL from a certificate status reporting component listed in the 
configuration store: if the ACRL is a c om plete CRL. then the CSS clears a cache 
memory associated with the issuing CA. determines the status from the CRL. and stores 
the statu s in the cache memory: and if the ACRL contains only changes occurring after 
publication of a full CRL. the CSS de termines the status from the ACRL. and stores the 
status in the cache memory. 

In another aspect of Applicants' invention, a method of retrieving a status of an 
authentication certificate issued by an issuing CA in response to a ouerv from a TCU to 
a CSS to validate the authentication certificate's status includes the step s of locating 
and reporting the status if the status is present and current in a cache memory of the 
CSS: and otherwise, performing the steps of obtaining a status type and retrieval 
method from a CSS configuration store: if the status type is CRL and the status is not 
found in the cache m emory, then reporting the status as valid: if the status type is not 
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CRL. then composing a certif icate statu s request according to the sta tus type; 
establishing a communication session with the issu ing CA: retrieving the status from a 
status reporting c omponent o f the iss uing CA using the obtained retrieval method and 
ending the communication session: interpreting the retrieved status: associating, with 
the interpreted ret rieved st atus, a time-to-live v alue rep resenting a period s pecified by a 
CSS policy for the status type: addin g at least the authentication certificate's 
identification, status, and time-to-live values to the cache memory: and re porting the 
status to the TCU in response to the Query. 

In yet another aspect of Applicants' invention, a C SS for providing accurate and 
timely status indica tions of a uthentication certificates issued by issuing CAs in cludes 
providing a status of an authentication certificate as indicated bv a CRL when the 
certificate 's issuin g CA uses CRLs for indicating status. Otherwise, the status as 
indicated b y a cache memory when the cache memory includes a status and a time^o^ 
live data element is not exceeded is provided. If the ti me-to-live d ata element is 
exceeded , the status is cleared from the cache memory r and the status is reguested and 
retrieved using a real-time certifi cate status reporting protocol when the status is not in 
the cache memory. At least the c ertificate's identification, status, and time-to-live data 
element are added to the cache memory, and the retrieved status is provided. 

A status use-counter data element may be added to the cache memory and 
incremen ted or decremented every time the certificate's status is checked. If the status 
use-counter data element passes a threshold, then the status is provided and the cache 
memory is cleared w ith respect to the status. A status last-accessed data element mav 
also be added to the cache memory, and the status last-accessed data element in 
conjunction with the status use-counter data element enables determination of an 
activity level of the certificate's status. 

When a reouest is made to the CSS to retrieve a status of a new certificate and 
the cache memory has reached an allocated buffer size limit, the CSS searches the 
cache memory for a lasted-accessed data element indicating an oldest date and clears 
the respective cache memory entry ; and the CSS then retrieves the reguested status. 
places it in the cache memory, and provides the reguested status. 

In vet another aspect of Applicants' invention, a method of executing a 
transaction between a first party and a second party by transferring control of an 
authenticated information object having a verifiable evidence trail includes retrieving 
from a trusted repository an authentica ted infor mation object that includes a fi rst digital 
signature block having a digital signature of a submitting party and a fi rst authentication 
certificate relating at least an identity and a c ryptogra phic key to the submitting party- 
executing the retrieved authenticated information object bv the second party bv 
including in the retrieved authenticated information object the second party's digital 
signature block, and forwarding the executed retrieved authenticated information object 
to a TCU. 

The TCU verifies the digital signatures and validates the authentication 
certificates associated with the digital signatures bv at least retrieving status of the 
authentication certificates from a CSS. The TCU rejects a digital signature block if the 
respective digital signature is not verified or the status of the respective authentication 
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certificate is expired or is re voked, and if at least one signature block in the information 
object is not rejected, the TCU appends the TCU's digital signature block and a date and 
time indicator to the information object and takes control of the object on behalf of the 
first party. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The various features and advantages of Applicants' invention will become 
apparent by reading this description in conjunction with the drawings in which: 

Figure 1 illustrates the-gJTCU electronic information object validation 
process that employs the CSSr; 

Figure 2 illustrates the-backg round CSS processing whereby CRLs and 
AACRLs are added to the certificate status storey 

Figure 3 illustrates separate caching of parsed CRLs, OCSP responses, and 
status derived from other certificate status reporting methods^ 

Figure 4 illustrates an extensible syntax for a signature block containing 
the example data elements where a digital signature is being applied to 
information object fragments and attached data (authenticated attributes)^; 

Figure 5 illustrates TCU interaction with a CSS and CSS retrieval of 
certificate status via the Internet from member and foreign CASt; 

Figure 6 illustrates the-aJTCU user enrollment process terminating in a 
certificate status checking step, where digital signature validation demonstrates 
successful enrollment^ 

Figure 7 illustrates tbe-gJTCU user enrollment process where a foreign CA 
issued the user certificate, terminating in a certificate status checking step, where 
digital signature validation demonstrates successful enrollment s and 

Figure 8 depicts an automobile-leasing example that shows how a CSS 

can be utilized in electronic commerce. 
RETAILED DESCRIPTION 

The certificate status check is a critical element to a system or TCU 
acceptance of any electronic information object submission. In order for a 
submission to be accepted, the certificate status must be reported as valid. 
Querying for certificate status normally requires that communications take place 
between the TCU and the source of certificate status. The frequency of these 
communications will grow in proportion to the number of TCU submissions. 

Checking of certificate status may be a real-time requirement and status 
queries are performed on every submission. However, status may not be updated 
in real-time as is the case with CRLs. AH CRLs are published at specified 
intervals, normally once or twice daily. CRL retrieval and repeated parsing can 
have a negative impact on system performance. This invention significantly 
reduces the direct computational and communication requirements by off-loading 
the bulk of the work to a C e rt i ficate Status S er v ice ( CSS). A single certificate status 
protocol is implemented between the TCU and the CSS. This status protocol may 
have attributes similar to the IETF Onlin e C e rt i ficate Status Protoco l ( OCSP) that 
allows the-an_application to query a CA for the status of a single certificate and 
thus minimize processing overhead. 
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The CSS is provided with and maintains sufficient information on the 
location, the means of communication and of processing certificate status for 
every CA that it needs to interoperate with. The CSS therefore makes it possible 
to stabilize and optimize the application design. The CSS advantageously parses 
and caches certificate status to minimize status response time to a TCU status 
query. The CSS therefore eliminates the need for any of the traditional forms of 
PKI interoperability. Potential compromise recovery is greatly enhanced since a 
TCU user account can easily be deactivated or a set of users eliminated by 
removing the CA from the CSS list of approved CAs. 



Us e of authenticat i on c e rtificates 
Use of Authentication Certificates: 

After logging into the TCU a participant may be asked to further 
authenticate themselves though use of public key cryptography and their 
15 authentication certificate. Such authentication may be associated with secure 
session establishment, requests for TCU services or the digital signing and 
submission of an electronic information object 

Before anyone can interact with a TCU, four conditions must be met: 1) 
they must first be enrolled as a system user, 2) they must have been issued and 
20 be in possession of a public-key pair and their matching authentication certificate 
if they are granted more than read-only access, 3) certificates must be issued by 
an approved CA, and 4) the user's certificate must not have expired or be reported 
as inactive or revoked. This last condition normally requires that the TCU direct a 
query to the issuing CA to retrieve certificate status. Because there are a wide 
25 variety of standards and CA implementations for reporting certificate status, this 
is not an easy or simple task. 

As stated in the background section, normally some form of PKI 
interoperability is required when multiple CAs or PKIs are involved. This 
invention eliminates this need by creating a Certificate Status Service. CA cross- 
30 certification or bridging is unnecessary as the only knowledge needed by the CSS 
is the list of approved issuing CAs, their IP addresses or the like , and their means 
of reporting certificate status. 

To retrieve certificate status, a connector or program module is defined for 
each certificate status method. Every authentication certificate contains both 
35 subject (user) and issuer (CA) fields. The issuer field is used to direct a TCU 
query to the CSS that then checks its cache for the presence of the certificate's 
status. If status is present in the CSS cache, it is returned to the TCU. If status is 
not present ± the CSS will invoke the appropriate connector to retrieve the 
certificate's status. Any number of methods will be used for reporting and 
40 retrieving certificate status^ LDAP, OCSP, CRL, etc. 

To perform any TCU action^ the user must first log into a TCU. Once 
successful, the user can create or select a transaction if they whe r e were granted 
such authority. If they have permission to submit electronic information 
obj e ct objects, they may now do so. Upon receipt of an electronic information 
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object the TCU performs the necessary digital signature validation steps. A 
certificate status query will be composed and sent to the CSS. If a valid status is 
returned ± the TCU will accept and store the submission as the authoritative copy, 
otherwise it will be rejected. 

D i g i tal signatur e proc e ssing and c e rt i ficat e status ch e ck i ng 
Digital Signature Processing and Certificate Statu s Checking: 

Digital signatures may be applied to one or more fragments or the total 
content of an information object. Digital signatures may belong to the parties to 
10 the transaction or to agents who enable the transaction to achieve a state or 

status within the context of a business process. Digital signatures may in fact be 
applied to additional information relating to the task being performed. One such 
example might be the county recorder's notation on a property deed. Another 
might be the application of the signature of the party attesting to the authenticity 
15 of the information objects being submitted to a TCU. In this Jate rtatter instance, 
the submitter is said to wrap or seal the information object in that their digital 
signature is applied to the full content ± preventing any subsequent modification. 

Whenever a digital signature is applied, the signer will be requested to 
affirm their intent to be bound by their digital signature. This commit action, that 
20 is required by recent legislation, may take the form of readable text in a display 

window or splash screen, and may require invocation of a graphical button and/or 
logon to a cryptographic token that is also a cryptographic key and certificate 
store. The actual demonstration of said willingness to commit is through the use 
of a trusted application that computes the user's digital signature using the 
25 selected content and combines it with their authentication certificate to the form a 
signature block. The signature block may also contain authenticated and 
unauthenticated data elements. Authenticated data elements are included in the 
digital signature computation ( e.g.. local date-time) and may be considered 
protected by the digital signature (integrity). Unauthenticated data elements are 
30 added after the signature computation and are not protected. Figure 4 shows a 
sample syntax that contains the data elements and layout of a signature block. It 
is not to be interpreted literally as it is only meant to be an illustrative example. 

The information object and any signature blocks may be advantageously 
placed in a wrapper (S/MIME) or at tags in an extensible information syntax (XML, 
35 HTML, XHTML) for handling convenience and to facilitate information processing. 
This data structure is then sent to the TCU for validation. Conversely, the 
signature block(s) may be sent independently to the TCU to be affixed to the 
actual source record which never leaves the TCU. In the late f latter case, each 
signature block is validated separately. 
40 The process for digital signature validation differs at the time of 

submission, from that performed thereafter. A four-step validation is performed 
the first time the TCU sees a digital signature: 1) verify the digital signature, a 
process that proves that the content protected by the digital signature has not 
been altered during transmission; 2) check that the current TCU time falls with the 
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allowable validity period of the individual's authentication certificate ("not 
before", "not after"); 3) request and retrieve certificate status from the issuing CA, 
CRL distribution pointy or another approved source of certificate status using the 
locally assigned CSS; 4) validate that the TCU user account information agrees 
with that conveyed in the certificate and that the requested action is authorized in 
the TCU rules database. For a submitter of the information object, the process 
adds one add i tion additional step. This fifth step checks that the submitter's 
identity matches that of the party who established the current session with the 
TCU. If all tests succeed, the action is allowed and/or the information object is 
accepted and held by the TCU on the behalf of its owner. If any step fails ± remedy 
is initiated. 

After this initial certificate status check, the trust environment of the TCU 
maintains the authenticity and integrity of all held information objects. It is not 
anticipated that any additional certificate status check will be needed unless a 
new version of the document is submitted. 

Two aspects of this invention differ from the normal course of PKI 
implementation. The first is that this invention is based on the existence of an 
application, namely the TCU (or any application/system requiring certificate status 
validation) and its ability to create and maintain electronic original source 
records. The second is that "issuing CA" need only be identified as complying 
with the policies governing the trust environment and that neither CA cross- 
certification nor PKI bridging is required. The necessary justification for "issuing 
CA" inclusion is a documented business relationship. During the TCU enrollment 
process, a user account is created that references user specific certificate 
information that in effect binds the user account with the user's authentication 
certificate. 

TCU usef Use: 

Typically once an organization agrees to utilize the services of a TCU, 
control over access to that organization's transactions is granted to agents of that 
organization. The organization's agents then identify a set of individuals whom 
they will empower to perform selected actions with regard to the organization's 
transactions. AH actions require that the user have an account with the TCU, that 
the account be activated, and that the user have a logon identity and be able to 
provide an appropriate password or response to a challenge phrase. In addition, 
each transaction, which is composed of a set of versioned electronic original 
source records, has a set of permissions that govern user access at different 
steps in the business process. This is exemplified by the granting and removal of 
rights to transaction records as the transaction proceeds though the normal 
course of business, i.e., inception through permanent retention or destruction. If 
permitted, only logon to the TCU is required to view an electronic source record. 
However, any systems level action or the introduction or changing of an 
electronic source r e cords record requires the individual to either further 
authenticate themselves by using public key cryptography or by applying their 
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digital signature and authentication certificate. In all instances, the identity of the 
individual must be validated. Where digital signatures are employed ± this entails^; 
1) that the user has appropriate access permissions, 2) decrypting the digital 
signature and verifying the contents over which the underlying hash or message 
digest has been applied have not been altered, 3) checking that the time of 
submission falls within the certificate validity period, and 4) checking that the 
user certificate is still valid. 

Certificate status checking requires that the issuing CA or a certificate 
status responder be queried. Since this step must be taken with every 
authenticated action or electronic source record submission, communication 
bandwidth may become excessive and potential exists for delays, backlogs, and 
rejections due to unanswered or slow status responses. This invention 
addresses these and other high assurance aspects of operating a TCU and 
ensuring the validity of all parties interacting with the TCU. 

In the highly assured environment in which the TCU is operated, certificate 
status checking is only needed when a service is requested by a qualified user. 
For information objects, certificate status need only be checked at the time of 
submission. If all digital signatures are determined to be valid, the information 
object is deemed authentic thereafter. Security and procedural practices and 
methods are in place at the TCU to prevent malicious actions and hardware 
failures that result unauthorized document alteration or loss. Every submission 
results in creation of a new version of an electronic source record. The TCU is 
charged with maintaining knowledge as to which is the latest version of the 
source record. This version may be identified as the electronic original and as a 
transferable record. The TCU demonstrates its assumption of control of an 
original source record by adding a reliable date-time stamp to the source record T 
and then by applying its digita ll y s i gn i ng and digital signature and appending its 
certificate. A wrapper may be applied to the source record for security and 
processing expediency. Although this versioning process creates a standalone 
authenticated trail-of-evidence and custody, separate redundant audit records are 
maintained for corroboration. 

A C e rt i fic a t e Stat u s Service is pr e s e nt e d that A pplicants' CSS overcomes the 
described limitations that persist today with PKI and e-commerce. Source 
information required to obtain certificate status from member CAs is registered 
with the CSS when they are created. Source information for foreign approved CAs 
may be entered during the user enrollment process. CSS retrieval information is 
required for every certificate status source. There are several types of certificate 
status sources and the CSS is required to have a connector or method for each 
ty pe r registered. 

One method used by some CAs to convey certificate status is called a 
C e rtif i cat e Revocat i on List. A the CRL . which includes a list of revoked certificates 
and the reason for their revocation, the issuer of the CRL, when the CRL was 
issued, and when the next version of the CRL will be published. Every CRL is 
signed by the issuing CA or a designated signer to assure its integrity and 
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authenticity. Certificates are removed from the CRL once their validity period is 
exceeded. 

Where CRLs are used, the CSS retrieves the latest rendition of the CRL 
from the CA distribution point, e.g., an X.509 v2 CRL profile (IETF RFC2459, Jan 
99), validates its signature, parses it, and creates a cache to store the results. The 
CSS uses a CA's CRL publication interval to govern when it performs the next 
CRL download. Every CRL contains a validity field that is normally set to allow 
some leeway in performing downloads. This allows for communications 
congestion and CA downtime and will force the CSS to require remedial action if 
10 this interval is exceeded. Such remedy may include revalidating any submissions 
that are associated with a newly added revoked certificate. Each new CRL 
supersedes the previously loaded CRL. The exception to this rule is for delta 
CRLs procession. The contents of a delta CRL are appended to the current cache 
contents. The delta CRL BaseCRLNumber refers to the most recent full CRL 
15 issued. Delta CRLs are published at shorter intervals (minute, hour) and only 
when a certificate revocation has occurred since the last full CRL. The CSS is 
responsible for retrieving CRLs and delta CRL based on publication interval or 
notification and not to exceed the interval established in the TCU, security policy. 
A second method used by CAs to distribute certificate status is the Online 
20 C e rt i ficat e St a tus Protoco l ( OCSP). Where OCSP is used the CSS queries the OCSP 
responder when asked for certificate status. OCSP responses are signed to 
guarantee their integrity and authenticity. The CSS parses the OCSP response 
and adds certificate details and status to another cache. A time-to-live flag, 
determined by local TCU security policy, is included with and determines when 
25 the entry will be removed from the cache. This feature is aimed at minimizing 
communications overhead when several information objects are be uploaded by 
the same party/entity to the TCU in a short interval. The time-to-live flag will 
usually be significantly shorter ( e.g.. 5 minutes) than the normal CRL publishing 
interval (twice daily, daily). The CSS may check certificate status again, if more 
30 than one information object was processed, prior to purging certificate status 
from the cache to ensure that certificate revocation has not occurred. If 
certificate revocation has occurred during the time-to-live interval, then the owner 
organization point of contact must be notified. Several other query methods 
exist, but will not be described for brevity. Be it understood that they will each 
35 require a connector and potentially a separate cache when they are utilized. 
Figure 1 shows the process flow n e c e ssary to cr e at e f or creating an 
electronic original. For the purpos e purposes of toe-description^ the information 
object is assumed to be a sales contract A n eS t o r ed 4, CQ Py (unexecuted) of the 
electronic information object is retrieved form from the TCU or from a document 
40 preparation system . An app li c a tion fo l low i ng th e proc e ss st e ps out l in e d in th e c l aims 
and is us e d i n e xecuting the contr a ct, digitally or holographically (handwritten) 
signed by appropriate parties. Having overseen the execution process, the 
owner's agent uses a trusted application to digitally sign and wrap the 
information object T and send it to a TCU. 
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Having previously created, executed or retrieved the electronic document, 
tfre-|LSufomitter digitally signs and submits it to the Trusted Custod i a l Ut i l i ty ( TCU) 
as in step 101. In the- this eSeal process tho system app li os ^ a wrapper that 
contains the signed content and digital signature block(s) that further contain the 
digital signature(s) and certificates(s) of the submitter and any other signatory J§ 
formed . There are five processes represented in th e figur e ; Figure 1: (1) action 
when an invalid digital signature(s) and/or revoked certificate(s) is found, (2) 
certificate status checking where status is locally cached, (3) certificate status 
checking where certificate status has to be retrieved, (4) CRL retrieval and 
processing, and (5) conc l ud i ng with cr e at i on o f creating an eOriginal when the eSeal 
document is determined to be authentic. In step 103 the TCU receives the 
eSealed electronic document. In step 105 the TCU validates that the submitter 
has authority to add the electronic document to the-^selected account and/or 
transaction. In step 107 ± the TCU cryptographically verifies any digital signatures 
included in the electronic wrapped digital electronic document. The public key, 
found in the signer's X.509 authentication certificate, is used during the 
verification process. In step 109 ± the certificate validity period is extracted from 
the signer's authentication certificate^ and in step 111-it -. the validity period is 
checked against the current date and time. If any of the before m e nt i ons mentioned 
tests fai! ± the submission is rejected in step 113 and a negative acknowledgment 
may be sent in step 114. The action is logged in step 117. 

If all tests succeed, thaf htherL certificate status for each certificate contained 
within the wrapper is requested from th e C e rt i ficat e Status S e rv i c e (^ CSS) in step 
119. In step-§tgc§ = 121 and 123 ± certificate status is checked to see if it is present 
in the-a^certificate status store. In step 125 ± certificate status is retrieved i and 
certificate validity ^checked in step 127. If any certificate is found invalid for any 
reason, the submission is rejected in step 113, a negative acknowledgment may 
be sent in step 115, and the actions action is logged in step 117. The submitter is 
expected to seek remedy. 

If in step 127 all digital signatures and certificates are determined to be 
valid for the submission, then in step 129 the TCU wi ll app l y applies another 
wrapper that includes a date-time stamp^- and TCU digital signature block. The 
TCU then assumes control of the submission as an electronic original record on 
behalf of the owner of record. In step 131 ± the TCU places the electronic original 
in protected persistent storage, in step 133 ± the TCU sends a positive 
acknowledgment, and in step 117 ± the TCU logs the actions just completed. 

If in step 123 it is determined m-that the certificate status is not present in 
the certificate status store, tha nthen the CSS in step 135 retrieves the issuing CA 
field from the certificate under test. In step 137 ± the CSS checks to see that the 
issuing CA is on the approved CA lis t, which may be maintained and accessed bv a 
CA Connector Store in step 139 . If the CA is not I isted4hafi - J Jhen_ a n invalid status is 
returned and the process resumes at step 12 5. Th e proc e ss _ and proceeds through 
stee steos 127, 113, 115, and 117 ± resulting in rejection of the submission and 
transmission of a negative acknowledgment and log entry. If the issuing CA is 
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found on the approved CA list in step 137 and in step 141 it is determined that the 
certificate status reporting meafis mechanism is a C e rtificat e R e vocat i on List ( CRL) 
t h a n T then a valid status indication is returned to step 125. If the CA is known and 
status is not present for the subject certificate, but the status m e ans i s by 
Certificat e R e vocat i on L i st (CRL), than mechanism is a CRL. then it may be assumed 
that the certificate status is valid ± providing a CRL exists and is current for the 
CA. The process thafh then proceeds through steps 127, 129, 131, and-133 , and 
1 17 T resulting in the creation of an electronic original, the transmission of a 
positive acknowledgment, and a log entry for the actions just completed. 

If in step 141 the certificate status reporting mean smechanism is determined 
not to be a CRL4haf i. then the connector information obtained in step 137 is used 
to query the certificate status reporting m e ans. mechanism. Contained in the 
connector description is all configuration information needed to query the 
appropriate certificate status repository, be it ilCA, ^directory, or any other type 
of certificate status repository. The status stores associated with steps 145, 147, 
149, and 151 (i.e., respectively, an LDAP directory, an OCSP resoonder. a database, 
and a server) are examples of such repositories. In response to the-a^query in step 
143 , one th e four st e ps (1 4 5 T 1 4 7 T 1 4 9. or 151) r e spond w i th c e rtificat e status of these 
responds with certificate status information, and the status is added to the certificate 
status store in step 153. 

Upon addition in step 153. the certificate status in -store process resumes at 
step 121 and continues through step -sjees_ 123, 125, and 127 to ^conclusion where 
the submission is either accepted (steps 129, 131, 133 . 117 ) or rejected (steps 113, 
115,117). 

CRLs are published in step 155 at predetermined intervals and in step 157 
as needed when a suspected compromise is reported and policy requires an 
immediate response. This process is further described in fiqwe -Fiaure 2. 

If the CA is knew -known and status is not present, and the status 
m e ans mechanism is other than a^CRL, the Certificate Status Service selects a 
connector and queries the certificate status means mechanism (step 44 2143 ). The 
connector contains the necessary information that makes status retrieval and 
interpretation possible. Any of the poss i b le sources of real-time certificate status 
depicted in steps 444 — 150, but not li m i t e d on l y to thes e m e thods J L4fL=JLM will 
respond to a certificate status query with current status , but this process is not 
limited only to those sources . Status is received i n st e p 152 and added to the 
Certificate Status Store in step 116 .153. When status is added, a response is 
generated and action returned to step 118 wh e r e in 1 23, with the processing of 
status r e sum e s resumina in step 126 and comp le t e s 125 and completing as d e scr i b e s 
described previously. 

Referring now to Figure 2, the Certificat e Status S e rvic e ( CSS) performs CRL 
retrieval as a background process. A CRL contains a list of all revoked or 
suspended certificates until the current date and time is beyond the validity 
period contained in the certificate. Suspended certificates are treated as if they 
have been revoked, but thev may be reinstated which results in their removal from 
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the CRL. Revoked certificates cannot be recovered. 

In step 155 ± a CA Administrator configures the CA to publish CRLs at 
predetermined intervals. In step 157 4 the CA Administrator may also manua l ly 
publish a Delta CRL as dictated by the local certificate or security policy. The CA 
Administrator or CA will push notice on publication of a Delta CRL. A d el ta CRLs 
A Delta CRL mav be generated whenever a certificate is revoked or suspended 
during the interval between publications of the full CRLs. Delta CRLs may contain 
a complete list of revoked CRLs. In step 201 ± CRLs and Delta CRLs are published 
to a CRL repository or directory. 

In step 203 ± the CSS retrieves the CRL publication schedules or Delta CRL 
notice . St e p ^ _and_step 205 represents a timer used for scheduled retrieval. The 
timer also allows retrieval based on the "next update" field contained in all CRLs. 
In step 207, the CRL or Delta CRL are-j^retrieved from the CRL repository. In step 
209 i the CRL or Delta CRL is parsed prior to being added in step 153 to an 
appropriate cache or list in the Certificate Status Store in step 121 or directory 
based on the established schedule or upon notification. Parsing the CRLs allows 
for easier management and reduced overhead in CRL entry lookup. Steps 119. 
123. 125. 135. 137. and 141 of the CSS are illustrated in Figure 2 for completeness, and 
are implemented as described in connection with Figure 1. 

Referring now to Figure 3, the Certificate Status Store contains a number of 
caches that hold certificate status from different reporting m e ans. mechanisms. 
The caches (five of which are depicted in Figure 3^ mav map to individual CAs of-a 
col le ction fcaches 301. 303) or collections of CAs (caches 307. 309) . For real-time 
reported status, the status will r e main remains in the cache until space is needed 
(gJLjeast frequently used) or based on a policy requirement (e.g.. hold for only a 
specified time interval). Status is normally purged once the cr i t e r i a criterion is 
exceeded. 

The purpose of the caches is to hold certificate status for a policy dictated 
period, thereby prov i d i ng a m e ans to r e duce reducino communications overhead 
required during certificate status and CRL retrieval. The CSS therefore prov ide s a 
m e ans to can_ bridge communications outages. 

CRLs may be parsed and the individual revoked certificate statuses placed 
in a cache to reduce computational overhead resulting when the CRL has to be 
checked repeatedly. This is depicted bv the caches 305. 307. The contents of the 
cache are replaced whenever a new full CRL is retrieved. 

Referring now to Figure 4, an example syntax is shown representing some 
of the more important data elements that need to be included in a digital signature 
block. Figure 4 is a free form example of data elements that make up a digital 
signature where the signature is applied to multiple me ssa ge fragments and a da te/time 
stamp. This example is meant to be illustrative of the syntax that mav be used for a 
digital signature block. It mav be noted that the <CumulativeHashValue> data element 
is applied to HashValues of one or more fragments or the total content and any 
Authenticated Data. 

Figure 5 depicts a secure communications architecture showing the 
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building blocks that support the Certificate Status Service. The figure shows the 
interaction among three CAs. the CSS, an d the TCU The CSS is preferably placed 
local to the TCU to guarantee high availability. Its primary purpose is to provide 
the TCU with a common interface 7 and to assur e ensure secure and timely provision 
ofcertificate status^-lt - information. Its secondary purpose is to i nsure e nsure a 
guaranteed level or Quality of service by managing communication and 
computational overhead required in maintaining certificate status , information. 

As seen in Figure 5. the CSS server and the TCU. wit h a suitable 
communications router and hub, are advantageously disposed behind a 
communic ations firewall. The router and hub direct information to the CSS and TCU as 
appropri ate. Some of this information comprises eSeal submissions th at are dir ected to 
the TCU as describe d above through a network such as the Internet from a User Client 
Application. Also depicted are CSS and TCU communications via OCSP 

Figure 5 als o depicts three CAs in different exemplary environments behind 
respectiv e communication firewalls. An Enterprise CA might comprise a server that 
interfaces with a Lease Industry CA enclosed bv the dashed lines A Foreig n PKI or 
Responder mioht co mprise a server that interfaces with entities such as a PKI, CA. and 
certificate status responder. A Hierarchical Member PKI mioht include a server that 
interfaces to entities such as a V3 LDAP for CRLs and certificate status, a Root CA and 
CAs for the mortgage and lease industries, l enders, closing agents, and title insurers 

Figures 6 and 7 depict the use of the Certificate Status Service during the user 
(subscriber and entity) enrollment process for both member CAs and foreign CAs ± 
respectively. A member CA is one that is trusted to issue user certificates. Foreign CAs 
are those operated by outside entities and need to be approved prior to their certificates 
being used in conjunction with TCU activities. User identity authorization needs to be 
rigorously enforced by all G ACAs or delegated to organization agents. Th e onoA n 
additional requirement is that a user's c e rt i f i cat o s certificate needs to be directly 
associated or authorized for use with one or more subscribing organizations' accounts 
before the TCU can grant access to that user. Once this is accomplished ± the TCU will 
accept the user's digital signature and rely gnjhe en-CSS for certificate status 
validation. 

In Figure 6, the TCU enrollment process starts at step 601 with receipt bv an 
organ i zation a dministrators/ag e nts r e c ei pt organization's administrator/agent of user 
enrollment information from a sponsor . In step 603 i this administrator/ aaent is 
charged with validating the sponsor's authority to make the request. Sponsors 
are normally only given control over their accounts. In step 605 i the 
administrator/aaent enrolls the user with the TCU. setting up a user account. In 
step 607 ± the administrator/agent may then assign t h e us er transaction privileges. 
Th e ab ili ty to the user. Transaction privileges may include abilities to submit, version, 
transfer, etc. electronic originals and other source records. 

In step 609 ± a cryptographic token (digital signature meafl smechanisml is 
initialized, and in step 61 1 ± a public-key pair ^generated on the tokenwn. In step 
61 3 ± a certificate request is created, and in step 61 5 ± the request is sent to the 
organization's CA. In step 61 7 4 the certificate is retrieved and Bkaee -placed on the 
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token. In step 619, the certificate is bound or associated with the user's TCU 
account 

In step 621 th e us e r i s r e qu e st e d to app ea r , the user's identity is validated, for 
example by appearing in person so that th e organization aaen tt o the organization's 
administrator/agent who can personally validate the user's identity. Normally, at 
least two forms of I D aro identification would be required. Since user participation 
is sponsored^ this should be sufficient except for high valued transactions where 
someone known to the administrator /agent may be asked to vouch for the user's 
identity. In step 623, the user is asked to sign a contract agreement whereby the 
user agrees that th e ir use of thetir -the user's digital signature is binding. In step 
625 ± the user is given an application user manual and whatever instruction is 
deemed necessary. In step steps 627 and 629. the user is provided with a-logon 
ID§, temporary passwords, and thei Mhe_ cryptog ra ph i c token. 

In step 631 ± the user is ask e d to l og logs_ onto the system^ and in step 633 ± 
submits a test document to the TCU. In step 635 i the TCU validates the user's 
digital signature and certificate. In step 637 ± the TCU queries the CSS for 
certificate status information . In step 639, the TCU receives status and 
pro c ee d proceeds accordingly. If the received certificate status is val§d ± enrollment 
completes at step 641 ± and the user is able to access and use the TCU. If the 
certificate status is invalid^ enrollment terminates^The in step 643 f and the 
administrato r must d e t e rm i n e / agent determines the cause of the error and 
i nst i tut e institutes remedy th a t mav r e quir e . which may involve repeating some or all 
of the outlined enrollment process steps. The reliable process outlined insu res in 
Figure 6 ensures that the enrollee is fully enabled at completion. 

in Figure 7, the user is allowed to use a cryptographic token previously 
issued by a foreign CA if policy dictated conditions are met. As 
pr e viouslv described above , enrollment steps 601 through 607 are followed. User 
identity verification and contract steps 621 through 627 are also followed^ as 
described above. 

Since the user already has a token ± the process deviates from that 
described in figwe Figure 6. In step 701 ± the user is ask e d to p l ac e th e ir places the 
token in a compatible reader and leg loqs on. In step 703 an Admin i strato r , an 
administrator application retrieves the user's certificate from the token. In step 
705 ± the certificate information is displayed and the Issuing CA identification 
information is obtained. The CA information is used in step 707 to verify that the 
CA is on thean approved list If the CA is not on the approved list, the CA 
information is provided to the TCU administrator in step 709 T and the adm i n istrato r 
checks with thean Application Policy Authority in step 711 for permission to 
continue enrollment. Only the Application Policy Authority can authorize adding 
a foreign CA to the approved list. 

If permission is denied in step 713. enrollment terminates^Th e in ste p 649. 
giving the user fcas-three options. One is to ask for and use a token issued by a 
member CA. Twe Another option is to request a review of the CA rejection decision. 
Tfrfe eThe third option is to ask for the names of previously approved foreign CAs. 
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If the issuing CA is approved^ but not on the lis t in step 713 , in step 715 the 
Administrator w ill b e dir e ct e d to add administrator adds the CA and connector 
information to the approved list . Th e Adm i nistrator w i l l also nood to configure^ 
configuring the CSS to retrieve certificate status from the CA. 

In step 61 9 ± the user's certificate is bound or associated with the newly 
created user account As in fiqweFioure 6 T and proc o ss steps 631 through 639, the 
user is asked to make a trial submission to the TCU to validate that the account 
has be- been set-up correctly and that the user can access the TCU. If the CSS 
returns valid status information, then enrollment completes at step 641. If the CSS 
returns invalid status ± then the administrator must d e t e rmin edetermines the cause 
of the error and i nst i tut e institutes remedy . This may r e qu i r e , which may involve 
repeating some or all of the out li ned e nrollment process steps des cribed above. 
The mu st most likely cause of failure may relate to the €SS-CSS's being able to 
reach and correctly retrieve certificate status from the foreign CA. 

The CSS plays a vital role in validating that the user certificate and issuing 
CA are both authorized in accessing a TCU or other system . If an issuing CA is 
removed from the approved list and its connector configuration data deleted, all 
associated users will-be- are denied further access to the TCU. It should be 
understood that the CSS can work with other applications and systems that require 
certificate status, inc luding ap plications a nd systems that require inter-working with 
multiple PKIs and CAs. 

For example, another use of the CSS is to provide status for trusted 
authentication certificates, including self-sianed certificates, where an agreement exists 
between the client seeking services and the application operator. A representation of a 
trusted certificate (e.g.. PEM. certificate ID. applied digital signature) is cached bv the 
CSS, and status is gueried using a trusted-certificate connector. This allows the 
application to have a single certificate status means regardless of whether the certificate 
was self-signed or issued bv a CA. This trusted-certificate method may be used where 
a small number of controlled certificates are used bv a community rather than Querying 
the community's CA or CAs. Thus, it will be appreciated that the terms "CA" and 
"issuing CA" as used in this application encompass such an accepted issuer of self- 
signed certificates as well as conventional CAs. 

Furthermore, the CSS may use a combination of connectors to retrieve certificate 
status. At least one connector may be "virtual", such as that iust described for use with 
trusted certificates. The CSS invokes connectors in a predetermined, e.g.. ordered, 
seouence until certificate s tatus is acguired. This method enables creation of a 
hierarchy of status sources (e.g.. most-trusted to least-trusted) . 

Figure 8 depicts an automobile-leasing example that shows how the CSS is 
utilized in e-commerce. The automobile dealer or the dealer's representative, hereafter 
called the dealer for simplicity, was issued a respective authentication certificate by an 
Automotive CA. which is depicted as a computer. The car's lessee, who mav be present 
at the car dealership, was issued a respective authentication certificate bv a Bank CA. 
A remote lessor was issued a respective authentication certificate bv a Financial CA. 
Alternatively, either lessee or lessor mav have created a self-signed certificate, which 
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the dealer registered with the leasing application and the CSS, for example because the 
lessee is a regular customer of the dealer. i 

As explained in this application, the CSS retrieves and reports status for these 
and other certificates using any certificate status reporting means that uses an approved 
status reporting protocol. In Figure 8. it is assumed that Automot ive CA a nd Financial 
CA use OCSP T that the Bank CA uses a CRL. a nd that the dealer and lessees have 
some forms of toke n (e.g.. P KCS#11 T PKCS#12. browser kev store, etc.) that contain 
their certificates and cryptographic signing means. It will be appreciated that Figure 8 is 
just an exemplar of execution of a transaction; more or fewer CAs may be connected as 
necessary with communications as necessary for the particular transaction. 

In step 801 . the dealer either originates the lea se contr act or retrieves it from a 
leasing application, such as a computer program running local ly at the d ealership or 
remotely at a remote site, e.g., on an Appli cation Ser ver. In step 803. the dealer 
orchestr ates the execution of the leas e by the lessee and lessor. The lease may be 
displayed to both the local lessee and the remote lessor at this time, and the dealer mav 
be called on to answer anv Questions and make corrections if needed., The dealer mav 
arrange for displayin g the lease to the lessor bv providing a URL (uniform resource 
locator) to the lessor that enables the lessor to review and execute the 1 lease, with the 
executed version returned to the dealer. After local signing bv the lessee and the 
dealer, for example with a tablet pc that captures the lessee's digital signature on the 
lease, and remote signing bv the lessor, the lease is transmitted (step 805) to an 
Electronic Vault, which is shown in communication with the Application Server. The 
digital signing by the lessee and dealer is advantageously dynamic, with the Application 
Server updating the displays bv applying a "digitally signed bv" indicator to the displayed 
imaoe(s). The actual digital signatures are preferably not displayed. ■ 

It will be recognized that the Application Server and associated Electronic Vault 
mav be used bv the dealer t o sta ge the contract for remote signing by the lessor. In 
steps 807 through 81 1 . the lessor retrieves the lease from the vault, agrees to the terms 
of the lease bv digitally signing it. and returns its digitally signed version to the vault- 
Steps 807 through 811 illustrate both multi-site collaboration and asynchronous 
transaction processing. 

In steps 813 through 817. the received electronic document(s) (the lease) are 
checked for digital signatures, and if anv are found, the digital signatures are verified 
and the respective authentication certificates are validated. In step 817. the local time is 
checked to ensure that it falls within the validity period( s) of the certificate(s). and in step 
819. the CSS is g ueried for the status of the certificate(s). In response in step 821. the 
CSS first checks its local cache memory or data store for certificate status, and if a 
certificate's status is present and current, the CSS returns the certificate's status as 
"active" i n step 82 7. In step 823. if certificate status is not present or not current, the 
CSS Qu eries the issuing CA using the connector type created for this purpose. In step 
825 T the issuing CA. e.g.. the Bank CA. or its status reporting means (e.g.. directory) 
returns status to the CSS, preferably using the same connector, and in step 827 r the 
CSS reports the gueried certificate's status back to the Application Server. 

Assuming all digital signatures and certificates are verified and validated, proving 
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the electronic document authentic, the Application Server assumes contr ol of the 
electronic document and saves it in the Electronic Vault as a new version in step 829. 
Thus T it will be seen that T w ith the proper characteristics, the Application Server and 
Electronic Vault cooperate as a TCU. In step 831 . the new version is designated as an 
authoritative copy, an Electronic Original that may also be a transferable re cord, bv 
appending a date-time stamp and appl ying the TC U's digital si gnature to the document. 
As long as at least one digital signature on a document is valid, this step takes place. 

In step 833. if any digital signature or certificate fails to pass all tests, th e dealer 
is alerte d to seek re med y, wh ich typic ally involves repeating steps 801 through 829 until 
valid rep lacement digital signatures are applied. The remedy process cannot be 
completed if the status of a signer's certificat e is revoked or expired until a new 
certificate and cryptographic material are issued. 

It will be understood that an information object, such as a lease for an 
automobile, may be presented in an electronic form, e.g.. XML r PDF r PKCS#7. S/MIME. 
etc.. that enables placement and detection of digital signatures and prevents 
unauthorized modification. Many of these forms therefore can be considered as 
providing security wrappers or e nvelopes for the included information. 

It will also be understood that the CSS can be used to check status of certificates 
regardless of kev usage. Such certificates include, but are not limited to. those for 
which the primary use is not identity and authentication, e.g.. kev agreement/exchange. 
certificate signing. C RL signing, key encryption, data encryption, encrypt only, decrypt 
only, and secure sockets layer (SSL). Accordingly, it will be understood that as used in 
this ap plication the term "authentication certificate" generally encompasses such 
certificates that are not used for identification. 

In addition, a CSS connector can advantageously embed more than one 
certificate status check in a single communication. Among other things, this capability 
mav be used in validating some or all of a chain of user/entitv certificates and CA 
certificates, e.g.. a hierarchy of CAs from a Root CA down to an issuing CA. This 
provides additional assurance that all CAs in the certifica te path are still valid. 

This application has described a method for configuring a Certificate Status 
Service (CSS) that includes the steps of determining setup information needed to 
retrieve certificate status for a reouisite issuing CA. identifying a connector compatible 
with a certificate status lookup technioue used to retrieve certificate status from the 
issuing CA. configuring the connector with setup and communications parameters 
specific to the selected connector and the issuing CA f and setting up a CSS mapping 
between the issuing CA and the connector. The CA designation and connector is added 
to a list of ap proved CAs in a configuration store. 

A method for executing a transaction bv transferring authenticated information 
objects h avin g respective verifiable evidence trails includes the step of retrieving, by a 
first party from a trusted repository, an authenticated information object. The 
authenticated information object includes a first digital signature of the submitting party. 
a first certificate relating at least an identity and a cryptographic kev to the submitting 
party, a reliable date and time, a digital signature of the trusted repository, a certificate 
relating at least the identity and cryptographic kev to the trusted repository: the digital 
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signature and certificate of the submittin g party having been validated bv the trusted 
repository at submis sion attesting to the information object's authenticity: and the 
authenticated infor mation o bject having been placed in storage as an electronic orig inal 
informatio n object placed under the co ntrol of the trusted repository. 

The transaction execution method further includes t he steps of reouirinq any 
signing entity to commit to use of and to be bound bv their dig ital si gnature prior to the 
act of signing, exe cuting sa id information ob je ct by any party , co nsists of inclusion of at 
least the digital signature an d authe ntication certificate of the signing party, creating a 
signature block th at contains at least the digital signature and authentication certificate 
of the si gning party, associating the signature block with the i nformatio n ob ject- 
re peating the previous execution steps where multiple entities digitally sign the 
information object and/or wrapper, and forwardin g the digi tally signed and/or wrapped 
information object to a TCU. The TCU verifies every digital si gnature and validates 
each associated a uthentic ation certificate and retrieves status from a CSS. The 
signature blocks are rejected if the signer's digital signature does not verify or a signer's 
authentication certific ate has expired or is reported to be revoked. Rejection of anv 
signature block results in a reouest for a replacement signature block or initiation of 
remedy. If at least one signatur e block is determined to be valid, the TCU appends its 
own signature block , also containing reliable date and time, to the subject information 
object, cr eating an electronic original which it holds and controls on behalf of the owner. 

Creating a digital signature block mav include the steps of computing one or 
more con tent hash es for the one or more information object fragments or for the whole 
information object, computing a hash over the one or more content hashes and any 
appended data, such as the local date and time, signing rationale, or an instruction- 
encrypting the computed hash using the signing party's private key, thereby forming the 
signer's digital signature, and placing the signer's digital signature in the signature block 
along with the signer's authentication certificate. If the appended data includes a local 
date and time, creati ng a digital signature block mav further include the steps of either 
displaying the local date and time, reouiring a signer to affirm that the date and time are 
correct, and correcting the local date and time if either is incorrect, or reiving on a 
system date and time if these are set bv a trusted time service and local date and time is 
protected from tampering. The local date and time can be checked to ensure that it is 
accurate and that it falls within the user's authentication certificate validity period and 
that the local data and time is not before and not after the dates and times specified bv 
the validity period- 
Remedy of a digital signature that fails to verify reouires the digital signature to be 
recomputed and the signature block to be retransmitted. Remedying a violation of 
authentication certificate validity period includes notifying the user th at the user's 
certificate has expired and must be renewed and notifying the transaction owner that the 
transaction is incomplete. 

Placement of one or more signature blocks and the information contained therein 
is specified bv at least one si gnature t ag. One or more handwritten signatures and 
dates are digitized and used for information object execution, and placement of the 
signature s and dates is specified bv at least one signature tag. One or more signature 
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blocks can be sent to the TCU separately along with the desig nation of the 
corresponding signature tags and the TCU can validate every sig nature block sent 
independently or as a group. If either the digital signature verification or authentication 
certificate validation step fails, the TCU rejects the signature block and may reguest 
remedy, and if the signature block validation step succeeds, the TCU pla ces the 
signature block at the indicated tag. To signature blocks sent separatel y, the T CU may 
add a reliable date and tim e to eac h signature block. According to business rules, the 
TCU appends its own signature block that contains a reliable date and time in a wrapper 
that encompasses the subject information object and inserted signature block fields, 
thereby creating an electronic original infor mation obj ect. Multiple user signatures 
blocks may be added within a wrapper, and wrappers can be recursively applied to 
implement other bus iness and security processes. 

The TCU mav validate the digital sionature(s) and authentic ation certificate(s) 
present in a signature block(s) that is/are to be contained within or is/are to be added to 
content of an electronic original information object by checking in the business rules 
database that the signing entity identified by the authentication certificate has authority 
to perform the reguested action, verifying the signing entity's digital signature, checking 
that certificate validity period overlaps current reliable date and time, checking that the 
conveyed local date and time falls within allowable deviation with the TCU date and 
time, and checking certificate status using a CSS. If any of these steps results in an 
invalid or false output, the digital signature is deemed invalid, the reguested action is 
disallowed and remedy sought: otherwise, the digital signature is deemed valid and the 
reguested action is allowed. 

Registration of an issuing CA with a CSS mav include the steps of vetting and 
approving the issuing CA for inclusion in a CSS knowledge base as "authorized" based 
on industry or organization business rules and system policy. If the vetting step fails. 
the issuing CA is added to the CSS configuration store as "not authorized" and/or CA 
registration terminates: otherwise, the issuing C A is add ed as "authorized", and the 
communication parameters (IP address. SSL kev and certificate) and the method used 
for reporting certificate status (OCSP. CRL. LDAP) are added to the CSS configuration 
store, and the connector to interpret certificate status is added if not already 
implemented. In this wav. the CSS enables interoperability between a system or TCU 
and a diverse set of certificate status resoonders. 

Certificate status checking advantageously employs a CSS for establishing 
communications, retrieving and caching certificate status from approved certificate 
issuing CAs. When CSS receives a certificate status ouerv from a system or TCU. the 
CSS first checks its local cache to see if the certificate status is present and if found and 
within the time-to-live interval, returns status. If certificate status is not present or 
outside the time-to-live interval, then the CSS retrieves status by first reouesting 
connection information from its configuration store. The CSS then establishes a 
communications session with certificate status reporting component identified in its 
configuration store. The CSS composes a certificate status reguest as per the method 
contained in CSS configuration store, and the CSS retrieves certificate status from the 
certificate status reporting component and closes session with component. The CSS 
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adds at least the certificate's ID, certificate status and time-to-live to its cache and 
returns certificate status to the requesting system or TCU. 

The certificate status reporting may be based on a CRL and processing of the 
CRL. According to the issuing CA's publication schedule, the CSS retrieves the CRL 
from the certificate status reporting component listed in the CSS configuration store. 
The CSS clears its cache memory associated with the issuing CA. parses certificate 
status from the CRL. and places the certificate status into its ca che ass ociated with the 
issuing CA. Upon notification by an issuing CA that a ~CRL is available, the CSS may 
retrieve the ~CRL from the certificate status reporting component listed in the CSS 
configuration store. Where it is reguired by standards that the ~CRL is a complete CRL. 
then the CSS clears the cache associated with the issuing CA T parses the CRL r and 
places the certificate status a nd relate d information into the cache associated with 
Issuing CA. Where the XRL contains only changes oc curring aft er publication of a full 
CRL r the CSS parses certificate status from "the CRL and places certificate status and 
related information into the cache associated with issuing CA. 

Using a CSS to obtain certificate status that allows a user, system or TCU to use 
a single means for obtaining certificate status can include the steps of Querying the CSS 
for the status of an authentication certificate present in a signature block on an 
information object, where the status ouerv may use a single means (e.g. r OCSP) r 
translating the status ouerv to a form reguired by the issuing CA r and retrieving and/or 
reporting certificate status. If certificate status is revoked, the signature block is not 
used and remed y is reguired: if the digital signature verifies and certificate status is 
valid, the signature block is added to the electronic original information object. 

The TCU can guery the CSS to validate a signer's authentication certificate status 
bv locating and reporting certificate status if the status is present and current in the CSS 
cache/data-store, and getting type and means for retrieving certificate status from the 
CSS configuration store. If the particular certificate status method is a CRL and the 
specified certificate's status is not found in the issuing CA cache in the CSS, then the 
CSS reports the certificate status as valid. If the certificate status method is not a CRL. 
then the CSS composes a certificate status reouest as per the method contained in CSS 
configuration store, and establishes appropriate communications with the issuing CA. 
The CSS retrieves certificate status from the status reporting component using the 
identified certificate status checking method and closes communications session. The 
CSS parses or interprets the retrieved certificate status, associates a time-to-live value 
eoual to the period specified by status type as stated in the CSS policy, and adds at 
least the certificate's ID. status, and time-to-live values to issuing CA's certificate status 
cache. The CSS then returns certifi cate stat us to reguesting system. 

A method for enrolli ng users in a system or TCU where certificate are issued by 
an approved issuing CA that is known to a CSS includes vetting the user using 
established membership procedures and criteria, entering user enrollment information 
that has also been signed bv an approved organization sponsor, and cre ating and 
sending a certific ate regu est to the identified issuing CA. The user's authentication 
certificate is retrieved, issued, and placed on a token for delivery. Digital signature, 
digital signature verification and the CSS certificate status check are performed to 



-28- 



Patent Application Ser. No. 10/620,817 
Mark-Up of Specification in Accordance with MPEP 704.11(a) 



ensure that public-key pair generation and certificate issuance process were completed 
correctly. The use r is requir ed to sign the user acceptanc e agreem ent that commits the 
user to give the same weight to use of their digital signature as they g ive t o use of his_or 
its hand written signature, the token is delivere d to the user T and the user's system or 
TCU account is activated. 

A method of enrolling users in a system or TCU where th e user already has a 
certificate issued bv a CA that is not previously known to a CSS can includ e querying 
the user's token for the user's authentication certificate and obtaining issuer information, 
and guervinq the CSS knowledge base to see if the issuing CA is contained therein. If 
not the industry or organization policy administrator is contacted to determine whether 
or not the issuing CA meets the system rules for CA inclusion. Where the issuing CAjs 
deemed " not auth orized", registration terminates, and where the issuing CA is deemed 
"authorized ", enrollment procee ds as descr ibed above. 

A portion of a user's authentication certificate contents may be used to bind the 
certificate to a user's account bv. after approving user for access to system or TCU. 
entering user enrollment information, inserting the user's token , that holds their 
authentication certifi cate, into a local token reader, retrieving and displaying the 
certificate contents, having the user affirm that the contents are correct, and adding 
selected fields to the system or TCU user enrollment data that is extracted from the 
certificate, such as certificate ID. issuing CA. a subset of the user's distinguished name 
or other identification informa tion conv eyed in certificate extensions (e.g.. 
subiectAl tNameV The extracted data may be specified in the system or TCU policy so 
that extraction and data entry may be automated. 

A method whereby a submitter of an information object vouches for the 
authenticity of a submitted information object includes the step of affixing the submitter's 
signature block to an information object and/or wrapper and forwarding it to a system or 
TCU. If signature block validation fails, the TCU reouests retransmission or remedy. 
and if signature block validation succeeds, the TCU then checks that the identity of the 
submitter matches that of the initiator of communication session, rejecting the 
submission if the initiator and submitter are different. If all checks succeed, the TCU 
adds its signature block to the submission, creating an electronic original information 
object. 

A method in a CSS of maintaining accurate and timely certificate status for real- 
time certificate status reporting means that employ a time-to-live data element includes 
these steps. If a CRL status method is used, then the CSS reports status. If certificate 
status is in cache and the time-to-live data element is not exceeded, then the CSS 
reports status. If the time-to-live data element is exceeded, the CSS clears the 
certificate status entry from the issuing CA cache. If status is retrieved using a real-time 
certificate status reporting means (e.g., QCSP. LDAP guerv. etc.) and status is not in 
cache, ce rtificate status is reouested. retrieved and reported. The CSS then adds at 
least the certificate's ID. certificate status and time-to-live to its cache and returns 
certificate status to the reou estinq s ystem or TCU. 

A certificate status use-counter data element mav be added to a certificate's 
status entry in the CSS's issuing CA cache, and the status use-counter can be 
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incremented or decremented every time a certificate's status is checked. If the status 
use-counter passes a threshold set bv CSS policy, then the certificate status may be 
reported, but the CSS then clears the certificate status entry from the issuing CA cache. 
If the CSS-returned certificate status is invalid or revoked, then the system or TCU logs 
and/or rep orts the error to the submitter and/or transaction owner, and the requested 
action is disallowed and remedy sought. Otherwise, the digital signature is deemed 
valid and the regues ted actio n is allowed. A cert ificate s tatus last- accessed data 
element may be added and us ed in co njunction with the use-counter to determine the 
activity level of the certificates' status. 
10 A backg r ound process can cause the CSS to automatically retrieve updated 

certificate status and establish new time-to-live and use-c ounter d ata eleme nts when a 
criterion in the CSS policy is met. This pre-fetch may be enabled to shorten the average 
time between system or TCU certificate status r eguest and CSS re sponse. 

If a reguest is made to th e CSS t o retrieve certificate status for a new certificate 
15 and the issuing CA cache has reached its allocated buffer size limit, the certificate status 
last-accessed data element may be added to the certificate's status entry in the CSS's 
issuing CA cache. The C SS searches the issuing CA cache for the latest-accessed 
data element for the oldest date (least-freguently-used) and clears that entry. The CSS 
then retrieves the reguested certificates status, places it in the freed l ocation in the 
20 issuing C A cache and reports the status to the system or TCU which acts according to 
policy. 

A method of status checking in a distributed CSS includes coordinating between 
CSSs whenever a new issuing CA is introduced, establishing entries in all CSS 
knowledge bases if another CSS has primary responsibility for gueryino an issuing CA. 
25 Querying other CSSs instead of an issuing CA to reduce communications between the 
CSS and issuing CAs. synchronizing and caching certificate statuses locally if multiple 
local systems have a heavy concentration of certificate status reouests against an 
issuing CA. and sharing or transferring the guerving responsibility if another CSS has 
heavier activity with a given issuing CA than the original primary CSS. 
30 Excluding a set of users associated with an issuing CA bv changing the issuing 

CA reference in a CSS knowledge base to "not approved" can be do ne by reg uesting 
that approval for the issuing CA be withdrawn, reviewing the reguest on merit and 
determining what if any action is needed, and if it is determined that for any reason the 
issuing CA should be disabled, then changing the issuing CA's status in the CSS 
35 knowledge base to "not approved". Any subseguent reguest for status of a certificate 
issued bv a CA listed as "not approved" results in the CSS returning a failed status. 

A method of re-enabling a set of users disabled by previously setting an issuing 
CA reference to "not approved" can be done bv reguesting that approval be granted for 
re-enabling the issuing CA, reviewing the reguest on mer it and de termining what if any 
40 action is needed, and if it is determined that the issuing CA should be re-enabled, then 
changing the issuing CA's status in a CS S knowledge base to "approved". The CSS 
processes certificate status reguests for reinstated issuing CAs as it would anv other 
"approved" CA. 

Communication with status reporting components can be established bv creating 
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a modular and reusable apparatus for each certificate status protocol used to locate, 
request and retrieve such information, using a version of the apparatus that is 
compatible with all CAs and responders that understand a particular certificate status 
protocol, and having a version of the apparatus for each status reportin g protocol that is 
in use. The apparatus is designed so that it is easily adaptable to support future 
certificat e status reporting protocols. 

Executing a transaction in which the submitter is a first TCU and the submission 
is to transfer custody of one or more electron ic origin als to a second TCU can include 
having th e owner of the transaction instruct the first TCU to transfer custody of one or 
more electronic original documents to a second TCU. The owner of the transaction 
instructs the second TCU to transfer custody of one or more electronic original 
documents, and the owner provides the first TCU with a manifest that identifies which 
electronic originals ar e to be transferred to the second TCU. The first TCU establishes 
communications with the second TCU T and identifies the purp ose of its actions to the 
second TCU. The first TCU or owner may transmit the manifest to the second TCU so 
that it is able to determine when the transfer of custody has been completed. The first 
TCU transfers each identified electronic original to the second TCU. which uses the 
CSS to ensure that the first TCU's digital signature on each transferred electronic 
original is valid and that the electroni c originals are unaltered. If anv of the first TCU's 
digital signatures are invalid, then the second TCU notifies the first TCU and seeks 
remedy (e.g.. asks the first TCU to resign using current authentication certificated If the 
first TCU is unable to comply, the second TCU loos the event and notifies the 
transaction owner that the reouested transfer of custody has failed: otherwise, the 
second TCU creates a new wrapper for each successfully transferred information object, 
adding a date-time stamp and its signature block. The second TCU notifies the first 
TCU of each successful transfer, and upon completion, the first TCU may at the 
discretion of the owner either mark and retain copies in such a manner that thev cannot 
be construed to be an original, or may destroy all copies that exist of the transferred 
information objects. The process is repeated until all identified electronic originals are 
transferred. In this way T the second TCU becomes the custodian for the transferred 
records that are the authoritative copies. The second TCU may append a reliable date 
and time , digitall y sign, wrap and store the manifest to make it an independent element 
of the trail-of-custody. 

In executing a transaction, the owner's instruction may also state that a transfer 
of ownership takes place, and transfer of ownership documentation mav be placed in 
either the first or second TCU. The responsible TCU validates the authenticity of the 
transfer of ownership documents bv verifying all digital signatures, certificate validity 
periods, and using the CSS to check certificate status. The TCU then appends reliable 
date and time, and digitally signs, wraps and stores these now electronic original 
information objects, which are added to the manifest. Where these electronic originals 
are placed in the first TCU. transfer-of-ownership is implemented prior to transfer-of- 
custodv. and the initiating manifest becomes part of the trail-of-ownership. 

Some of the transferred records may be simple electronic information objects and 
not iust electronic originals. The CSS mav use anv appropriate certificate status 



-31 - 



Patent Application Ser. No. 10/620,817 
Mark-Up of Specification in Accordance withjMPEP 704.11(a) 



protocol to communicate with a system or TCU. 

This invention can be embodied in many different forms wit hout de parti ng from its 
essential character, and thus the embodiments described above shou ld be considered 
illustrative, not restrictive, in all respects. It is emphasized that the terms "comprises" 
and "comprising", as used in this description and the fo llowing claims, are meant as 
specifying the presence of s tated fea tures witho ut precl uding the presence of one or 
more other features. The intended scope of the invent ion is se t forth by t he following 
claims, rather than the preceding desc ription, and all variations that fall within the scoge 
of the claims are intended to be embraced therein. 
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What is ctaimed is: 



(CLAIMS NOT SHOWN - PLEASE REFER TO CURRENT CLAIMS OF RECORD) 



I 
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-ABSTRACT 



Th i s invention e laborates on tho A Certificate Status Service that is configurable- 
directed, and able to retrieve status from any approved Certification A uthority (CA) is 
disclosed. The CSS mav be used bv a Trusted Custodial Utility (TCU) and 
comparable svstem svstems or applications whose roles ift -are validating the right of 
an individual to perform a requisite action, the authenticity of submitted electronic 
information objects, and the status of the-authentication certificates used in tshe 
digital signature verification and user authentication processes. The validity 
10 check on authentication certificates is performed by querying tfrean issuing 
Certificat i on Authority ( CA). Traditionally, to create the-^trusted Public Key 
Infrastructure (PKI) e nv i ronm e nt needed to validate certificates, complex 
relationships are formed by cross-certification amongst CAs or by use of PKI 
bridges. Th e s e approaches h a v e prov e d cumb e rsom e and unm a nag e ab le . 
15 Th i s i nv e nt i on a pproach e s th e The PKI and CA interoperability problem j§ 

addressed from a tota ll y different point of vie w. As in App li cants' e ar lie r inv e nt i ons, 
o w T with a focus is-on establishing a trust environment suitable for the creation, 
execution, maintenance, transfer, retrieval and destruction of electronic original 
information objects that may also be transferable records (ownership may change 
20 hands). A TCU is eftfy-concerned only with a known set of "approved CAs" ever* 
although they may support a multitude of business environments ± and within that 
set of CAs ± only with those certificates that are associated with TCU user 
accounts. Any oth e r c e rt i fic a t e w il l be i gnor e d. This r e s ul t e d i n the i nv e nt i on of a 
C e rt i ficate Status Serv i c e that is configurab le , d i r e cted, and a bl e to r e tri e v e status from 
25 any approv e d CA. Building PKI/CA trusted relationships is not required - as the 
CSS achieves a trusted environment by querying only approved CAs and maintaining 
caches of valid certificates' status. 
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